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BY Emmanuel Polonowski 
LACL, University Paris-East Creteil 
Email: emmanuel .polonowskiOu-pec . f r 

Abstract 

We introduce a library which provides an abstract data type of environments, as a functor 
parameterized by a module defining variables, and a function which builds environments 

for such variables with any Type of type. Usual operations over environments arc defined, 
along with an extensive set of basic and more advanced properties. Moreover, we give an 
implementation using lists satisfying all the required properties. 



1 Introduction 

A standard usage of proof assistants is to define type systems for a wide range of formal lan- 
guages, and to prove properties about them. To achieve this goal, one has to work around the 
notion of typing environment, from the definition of the type system up to the core of the 
proofs. The definition of such typing environments is mainly a programming activity, but it 
often requires to prove a lot of small uninteresting (and easy to prove) lemmas that eventually 
are packed in some auxiliary file, unordered and probably redundant w.r.t. themselves. 

Among his libraries for the locally nameless infrastructure (see [1]), Arthur Chargueraud pro- 
posed some years ago a generic module for environments, that contained a function which builds 
environments for a given type, specialized for a previously defined notion of variable. This 
library was an elegant way to deal (almost) abstractly with environments. 

The work we present here is a complete rewriting of this library of environments, reorganized 
and augmented in several ways. Firstly, it has be written in Coq v8.3 without any use of addi- 
tional library or tactic; we believe it to be more stable than its previous version. Secondly, 
instead of importing a module with the definition of variables, we define our library as a functor 
parameterized with such a module, requiring only the decidability of equality over the variables. 
Thirdly, the set of basic operations has been extended with : a remove operation for a single 
variable or a list of variables, and an update operation which changes the types associated to 
variables accordingly to another environment. Fourthly, we added an equivalence relation over 
environments, based upon environment bindings inclusion, which can be used to work on the 
theory of typing environments. Fifthly, as we follow Chargueraud in providing an implementa- 
tion of environments with lists, we enforce the abstract-data-type discipline with the help of the 
module system of Coq. 

We tried to be as exhaustive as possible in the choice of the provided properties, and with 
the least possible redundancy. We believe that the set of around 250 basic and more advanced 
properties might be enough for any use of this library. As a final and validating property, we 
prove the equivalence between updating an environment with a binding and adding it after 
having removed the previous binding. Even if the result is of few theoretical interest, it ensures 
that the definitions are sufficient to prove arbitrary abstract properties over environments. 

The paper is organized as follows: Section 2 briefly describes the basic definitions of our envi- 
ronments. Section 3 exhibits several standard properties of environments and the proof of equiv- 
alence between updating and removal followed by concatenation, Section 4 concludes with a dis- 
cussion about environments and choices of implementation. 

Source code and automatically generated html documentation are of course available [3]. 
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2 Defining a generic notion of environment 

2.1 Structure of the library 

The structure of the library is given by three Ubrary files organized as follows. 

Firstly, the module of variables, that has to be implemented and then given as parameter to 
the generic environment functor. 

Module Type Generic_Var. 
Pareimeter TVar : Type. 

Pareuneter eq_var_dec : forall x y : TVar, {x = y} + {x <> y}. 
End Generic_Var. 

As one can see, its definition requires only the decidability of equality, but it could be aug- 
mented with additional definitions if it were to be used, for instance, to define a module which 
deals with freshness. 

Secondly, the functor of abstract generic environments, which is parameterized by the 
module of variables. 

Module Type Generic_Env_Type (Var : Generic_Var) . 
End Generic_Env_Type . 

Thirdly, the functor of generic environments implemented with lists and the opaque exported 
functor. 

Module Generic_Env_List_Def (Var : Generic_Var) . 
End Generic_Env_List_Def . 

Module Generic_Env_List (Var : Generic_Var) : Generic_Env_Type (Var) := 
Generic_Env_List_Def Var. 

The module Generic_Env_List is the opaque functor to be used by the library users. 

2.2 Bzisic definitions of environments 

We present here the basic definitions of environments. 
The main function of the module is the following: 

Pareuneter gen_env : Type -> Type. 

It takes as a parameter the type of types that are to be associated with variables in the 
returned environment. 

Two operations are defined to build environments with a single binding and several bindings 
given as a list of variable and a list of type: 

Pareimeter single : TVar -> A -> gen_env A. 

Pareimeter singles : list TVar -> list A -> gen_env A. 

The basic operations on environments are the concatenation of two environments, the 
retrieving of a type associated to a variable that might belongs to it (we use the option type), 
the domain and the image of the environment seen as a sort of mapping: 

Pareimeter concat : gen_env A -> gen_env A -> gen_env A. 
Pareimeter get : TVar -> gen_env A -> option A. 
Pareimeter dom : gen_env A -> list TVar. 
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Parcuneter img : gen_env A -> list A. 

We provide as a basic operation the updating of an environment with the binding of another 
given a parameter. More exphcitly, when updating an environment T with A, the resulting envi- 
ronment binds as T for the variables that are not in A, and as A for the variables of T that 
appears in A. 

Pareimeter update : gen_env A -> gen_env A -> gen_env A. 

At last, we provide two operations to remove bindings by their variables: 

Pareuneter remove : TVar -> gen_env A -> gen_env A. 
Pareiineter all_remove : list TVar -> gen_env A -> gen_env A. 

The basic set of predicates over environments includes the tests of membership: 

Parcuneter belongs : TVar -> gen_env A -> Prop. 
Pareuneter all_belongs : list TVar -> gen_env A -> Prop. 
Parcuneter notin : TVar -> gen_env A -> Prop. 
Parameter all_notin : list TVar -> gen_env A -> Prop. 

Of course, the main predicate is the binding assertion, to be used in the typing rules of a 
type system: 

Definition binds (x : TVar) (v : A) (E : gen_env A) := get x E = Some v. 

The extension of binds to several associations give rise to a notion of environment inclusion, 
defined as follows: 

Definition all_binds (E F : gen_env A) := forall x v, binds x v E -> binds x v F. 

We added a predicate of environment equivalence, defined as their mutual inclusion: 

Definition eq (E F : gen_env A) := all_binds E F /\ all_binds F E. 

Up to now, we deal with environments that possibly contain several bindings for the same 
variable. The following predicate assert the non-duplication of variables (where & is the concate- 
nation of environments): 

Inductive ok : gen_env A -> Prop := 
I ok_nil : ok (©empty A) 

I ok_cons : forall x v F, ok F /\ x ^ F -> ok (F & (x : v)). 

Environments that are ok will have more properties, as the the commutativity of concatena- 
tion for instance. 



3 Some properties of generic environments 

Among the wide set of properties of environments, we find structural properties which helps to 
reason about the definitions, basic properties useful for more complex properties and external 
proofs, and advanced properties that might not be of any external use, but which provides intu- 
itions about the robustness of our definitions. Here follows several properties organized in that 
order. 

3.1 Structural properties 

The simplest structural properties are those stating the neutrality of empty environments w.r.t. 
concatenation, and the associativity of the concatenation: 
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Parcimeter concat_empty_r : forall E, E & ((Sempty A) = E. 
Pareimeter concat_empty_l : forall E, (Oempty A) & E = E. 
Parameter concat_assoc : forall E F G, E & (F & G) = (E & F) & G. 

Properties about the construction of an environment from a list of variable and a list of type 
helps to catch the minimal requirements of the implementation: 

Parameter singles_empty : nil :: nil = ((Sempty A) . 
Parauneter singles_cons : forall x xs v vs, 

(x : : xs) :: (v : : vs) = (xs :: vs) & (x : v) . 

The ok predicate presented above was taken from the original implementation of Char- 
gueraud. However, an interesting (almost) structural property is the equivalence between that 
predicate and the non-duplication of the domain of the environment, stated as follows: 

Pareimeter ok_NoDup_dom_eq : forall E, ok E <-> List.NoDup (dom E) . 
3.2 Basic properties 

We find also more complex properties, along with their inverse, that are mainly to be used in 
external proofs. For instance, the ok predicate for the concatenation of two environments: 

Paraimeter ok_concat : forall E F, 

ok E -> ok F -> 

dom E ? -> dom F E -> 

ok (E & F) . 
Parameter ok_concat_inv : forall E F, 

ok (E & F) -> 

ok E /\ ok F /\ dom E (;£ F /\ dom F (fi 'E. 

A lot of properties talks about the interactions between operations and predicates. For 
instance, the following property states that when we perform the updating of an environment 
with another which contains only disjoint bindings, then nothing happens: 

Parcuneter update_notin : forall E F, 
(dom F) E -> (E : := F) = E. 

The most important properties about environments are certainly those talking about bind- 
ings. The following one are very standard: 

Parameter binds_eq_inv : forall xvwE, x : v S E->x : w € E->v=w. 
Parameter binds_concat_r : forall xvFG,x:veG->x:ve (F&G). 
Pareimeter binds_belongs : forall xvF, x : v g F->x S F. 

The inverse property of the last one is also quite useful: 

Paraimeter belongs_binds : forall x F, x e F -> exists v, x : v e F. 

We provide two decidability properties of the binds predicate. The first one for the existence 
of a binding for a given variable: 

Parameter binds_dec_exists : forall x E, 

{v|x:veE} + { forall v, -■ x : v e E }. 

The second one is the more usual decidability of the predicate. However, it requires the 
decidability of the equality over types in order to be provable: 

Pareimeter binds_dec : forall x v E, 

(forall w w', { w = w' } + { w = w' }) -> 
{x:veE} + {-.x:veE}. 



Discussion 



5 



3.3 Advanced properties 

When dealing with binding, environment inclusion and equivalence, we get to more complex 
properties. Here follows the decidability of the existence of a list of types associated with a 
given list of variables in an environment (where E C F is the environment inclusion): 

Pareiineter all_binds_dec_exists : forall xs F, 
List.NoDup xs -> 

{ vs I length xs = length vs /\ (xs :: vs) CP} 

+ { forall vs, length xs = length vs -> (xs :: vs) C F }. 

Environment inclusion is an order, as the following properties says (where is the equiva- 
lence over environments): 

Parameter all_binds_ref 1 : forall EF, E=F->E C F. 

Parcuneter all_binds_anti_sym : forall EF, E C F->F C E->E x F. 
Parameter all_binds_trans : forall EFG,E C F->F C G->E C G. 

Moreover, we require that equivalence over environments satisfies the usual properties: 

Parameter eq_refl : forall EF, E=F->E >; F. 

Parameter eq_sym : forall EF, E x F->F x E. 

Parauneter eq_trans : forall EFG, E x F->F x G->E x G. 

With this equivalence, we can state interesting abstract properties, such as the commuta- 
tivity of concatenation when environments are ok: 

Parconeter eq_concat_comm : forall E F, ok (E & F) -> (E & F) x (F & E) . 

As a final example, we try to reason about operations on environments at this suitable 
abstract level. The following property assert the equivalence of updating and removal plus con- 
catenation: 

Parameter update_is_remove_concat : forall x v E, 
X e E -> (E : := (x : v)) X ((E \ {x}) & (x : v)). 



4 Discussion 

Should environments be built upon association lists or maps ? 

This is a natural question since environments are usually implemented as association lists. It 
is true that this library could be split in two parts: a library for association lists on one hand, 
and environments built upon it on the second hand. The critical point is about the duplication 
of variables: maps usually preserves the non-duplication of keys, while association lists are insen- 
sible about it. Here the choice is to allow duplication, discarding the use of Coq library for 
maps. 

It will be interesting to develop a library for association lists, with enough basic properties to 
lighten the environment library. 

Should environments assume that no variable is duplicated ? 

Traditionally, no assumption is made on the duplication of variables in a typing environ- 
ment, either discarding the question at the meta-level, or defining environment as stacks (or 
even both, using it as a stack without saying it). Indeed, the stack discipline works fine for envi- 
ronments even in presence of a-equivalence, since the typing relation is built structurally to 
respect the scope of binders. Our generic environment clearly enforces the stack discipline w.r.t. 
the concatenation to the right, stated informally by several properties (mainly binds_concat_r 
vs. binds_concat_l). 
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Could we state the non-duplication as a parameter of environments, and use only that kind 
of environments in every type systems ? The answer is no. Some languages are strongly built 
upon the stack discipline to encode different notions of binding, as in [2], and need to preserve 
all the occurrences of the same variable which are clearly distinct one from each other. There 
are other formal languages that are built upon slightly different notions of binding, and they 
would probably suffer for a lack of flexibility a notion of environment enforcing the non-duplica- 
tion. 
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